a? r 



"Express Mail" mailing number: ER530238353US 
Date of Deposit June 2, 2006 



I hereby certify that this correspondence is being deposited with the 
United States Postal Service "Express Mail Post Office to Addressee" 
service under 37 C.F.R. 1.10 on the date indicated above and is 
addressed to the Commissioner for Patents, P.O. Box 1450, 



VA 22313-1450 





PATENT 



IN THE UNITED STATES PATENT AND TRADEMARK OFFICE 



Mason et al. 
09/627,253 
July 28, 2000 



Group Art Unit: 2665 
Examiner: Nguyen, Toan D. 



For: 



PRESENCE REGISTRATION AND ROUTING NODE 



********** 



APPEAL BRIEF UNDER 37 C.F.R. 5 41.37 

Commissioner for Patents 
P.O. Box 1450 
Alexandria, VA 22313-1450 

Sir: 

This is an appeal pursuant to 35 U.S.C. § 134 from the Examiner's decision 
rejecting claims 1-10, 22-34, 42-50, 61-66, 69-72, 75 and 76 as set forth in the Office 
Action of September 2, 2005. 



\. Real Party in Interest 

The real party in interest is Tekelec, a California corporation, and the assignee of 
the inventors' entire interest. 



0&/06/E00& fiftHHEM 00000002 0%£7253 

0i FC:i40E 500 - 00 0P 



Serial No.: 09/627,253 

II. Related Appeals and Interferences 

There are no appeals or interferences, known to appellants or appellants' legal 
representative which will directly affect or be directly affected by or have a bearing on 
the Board's decision in the pending appeal. 
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IN. Status of Claims 

Claims 1-78 are pending in the subject application. Claims 35-41, 73, and 74 are 
allowed Claims 11-21, 51-60, 67, 68, 77, and 78 are withdrawn. Claims 1-10, 22-34, 
42-50, 61-66, 69-72, 75, and 76 stand finally rejected by the Office Action of June 2, 
2005, and are the subject of this Appeal. 
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jV. Status of Amendments 

Appellants received an Office Action dated June 2, 2005, finally rejecting claims 
1-10, 22-34, 42-50, 61-66, 69-72, 75, and 76 and requesting that withdrawn claims 11- 
21, 51-60, 67, 68, 77, and 78 be canceled. 

Appellants filed an Amendment after Final Rejection on December 2, 2005, 
canceling claims 11-21, 51-60, 67, 68, 77, and 78 and making a clarifying amendment 
to allowed claim 35. 

Appellants received an Advisory Action dated December 28, 2005 indicating that 
the proposed amendments to the claims will not be entered for purposes of the appeal. 
The Amendment After Final Rejection dated December 2, 2005 requested that the word 
"communication" be replaced with "communications" in line on claim 35. The purpose 
for the amendment was for consistency with the remaining references to the 
"communications medium" in the remaining portions of claim 35. Because this 
amendment does not add any new matter or raise any new issues, Appellants 
respectfully request that the Board direct the Examiner to enter the proposed 
amendment to claim 35. 

With regard to withdrawn claims 11-21, 51-60, 67, 68, 77, and 78, because the 
Advisory Action indicates that the amendments to the claims in the Amendment after 
Final Rejection dated December 2, 2005 were not entered, the status of these claims 
remains "withdrawn." Accordingly, the attached Claims Appendix includes withdrawn 
claims 11-21, 51-60, 67, 68, 77, and 78. 
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V. Summary of Claimed Subject Matter 

Independent claim 1 recites a method for updating presence information 
regarding a target end user in a presence database based on information derived from 
a telephony-related action. Examples of telephony-related actions described in the 
present specification are registration of a wireless customer in a particular cell or service 
area (see page 26, lines 7-18 of the present specification), the placement of a wireline 
telephone call (see page 27, lines 6-19 of the present specification), or the dialing of a 
code via a telephone keypad (see page 28, lines 3-13 of the present specification). 
Each of these actions results in generation of an SS7 message, which is normally used 
for call setup, mobility management, or a database query, depending on the message 
type. However, claim 1 recites a method by which such an SS7 message triggers 
generation of a presence registration message. 

In claim 1, the method includes receiving a signaling system 7 (SS7) message 
(Figure 8, location update message 412, Figure 9, ISUP IAM message 428, or Figure 
10, TCAP message 448) in response to a telephony-related action performed by a 
target end user (Figure 8, mobile subscriber 402, Figure 9, wireline subscriber 422, or 
Figure 10, wireline subscriber 442) to which other end users are subscribed in a 
presence database (Figure 8, presence server 410, Figure 9, presence server 426, 
Figure 10, presence server 446, or Figure 1 1 , PDM 502). One example of receipt of an 
SS7 message appears on page 25, line 23 through page 66, line 1 of the present 
specification where a location update message is received by presence registration and 
routing node 300 in Figure 8. A location update message may be generated when a 
mobile subscriber registers his or her handset with base station 404 (Figure 8). 
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Normally such messages are routed to the subscriber's home location register (HLR), 
as indicated by the location update message proceeding to HLR 408 illustrated in 
Figure 8. 

However, rather than simply routing the location update message to the HLR, 
claim 1 recites determining, based on the SS7 message (Figure 8, location update 
message 412, Figure 9, ISUP IAM message 428, or Figure 10, TCAP message 448) 
whether presence registration processing is required for the target end user (Figure 8, 
mobile subscriber 402, Figure 9, wireline subscriber 422, or Figure 10, wireline 
subscriber 442). An example of determining whether presence registration processing 
is required for the target end user is described for ISUP messages on page 20, lines 7- 
16 of the present specification and for TCAP messages on page 24, line 16 through 
page 25, line 2 of the present specification. The location update message illustrated in 
Figure 8 is an example of a TCAP message that may require presence registration 
processing. An example of an ISUP message for which presence registration 
processing may be required is ISUP IAM message 428 illustrated in Figure 9. An 
example of a non-mobility-management TCAP message for which presence registration 
processing may be required is TCAP message 448 illustrated in Figure 10. 

Claim 1 further recites, in response to determining that presence registration 
processing is required for a target end user (Figure 8, mobile subscriber 402, Figure 9, 
wireline subscriber 422, or Figure 10, wireline subscriber 442), automatically generating 
a presence registration message (Figure 8, registration message 416, Figure 9, 
registration message 434, or Figure 10, registration message 450) including presence 
information usable by a presence server (Figure 8, presence server 410, Figure 9, 
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presence server 426, Figure 10, presence server 446, or Figure 11, PDM 502) for 
automatically indicating to end users who are subscribed to the target end user (Figure 
8, mobile subscriber 402, Figure 9, wireline subscriber 422, or Figure 10, wireline 
subscriber 442) in a presence database (Figure 8, presence server 410, Figure 9, 
presence server 426, Figure 10, presence server 446, or Figure 11, PDM 502) a 
presence status for the target end user (Figure 8, mobile subscriber 402, Figure 9, 
wireline subscriber 422, or Figure 10, wireline subscriber 442).. The generation of a 
presence registration message in response to receipt of an ISUP IAM message is 
described on page 22, lines 4-6 of the present specification. The generation of a 
presence registration message in response to receipt of a TCAP message is described 
on page 24, line 24 through page 25, line 2 of the present specification. 

An important concept in the presence protocol that is different from mobility 
management protocols used by the mobile call signaling network to track a subscriber's 
location is that using the presence protocol, subscribers can subscribe to another 
subscriber in a presence database to receive presence status updates when the 
presence status of the subscribed-to entity changes. For example, as described on 
page 4, lines 14-24 of the present specification, the presence protocol allows an entity A 
to subscribe to another entity B in a presence server P. When the status of B changes, 
P will notify E of the change in status of B. Thus, the presence protocol includes the 
concept of allowing one end user to subscribe to another end user for the purpose of 
receiving presence status for the target end user. Independent claim 1 recites a method 
for updating presence information for a target end user in response to receipt of an SS7 
signaling message so that other end users who are subscribed to the end user will 
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receive status updates when the target end user performs a telephony-related action, 
such as activating a mobile handset, attempting a wireline call, or dialing a special code 
on a wireline phone. Deriving and automatically updating presence status from SS7 
signaling messages increases the likelihood that the presence status to the target end 
user will be accurate and current. 

Independent claim 5 recites a method for updating presence information 
regarding a target end user in a presence database based on information derived from 
a signaling message relating to a telephony-related action performed by the target end 
user. The method includes receiving an SS7 signaling message (Figure 8, location 
update message 412) in response to a telephony-related action performed by a target 
end user (Figure 8, mobile subscriber 402). Claim 5 further recites that the telephony- 
related action is the activation or change in location of a mobile telephone handset and 
that the SS7 message is a message for updating the status of the target end user 
(Figure 8, mobile subscriber 402) in at least one of a home location register (HLR) 
(Figure 8, HLR 408) and a visitor location register (VLR) (not shown in Figure 8). The 
receipt of the location update message by presence registration and routing node 300 is 
described in page 25, line 23 through page 26, line 1 of the present specification. 

Claim 5 further recites intercepting the SS7 message (Figure 8, location update 
message 412), extracting information from the SS7 message (Figure 8, location update 
message 412) and using information extracted from the SS7 message (Figure 8, 
location update message 412) to update presence information for the target end user 
(Figure 8, mobile subscriber 402) in a presence database (Figure 8, presence server 
410 or Figure 11, PDM 502). Claim 5 further recites that the presence information 
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includes information usable by a presence server (Figure 8, presence server 410 or 
Figure 1 1 , PDM 502) for automatically indicating to end users who are subscribed to the 
target end user (Figure 8, mobile subscriber 402) a presence status for the target end 
user (Figure 8, mobile subscriber 402). The concept of a subscriber subscribing to 
another subscriber in a presence database is described on page 4, lines 14-23 of the 
present specification. The updating of presence information in response to a message 
transmitted to an HLR or a VLR is described, for example, on page 26, lines 4-18 of the 
present specification. 

Thus, independent claim 5 recites a method where a presence information 
update for a target subscriber is generated in response to a telephony-related action 
that causes an SS7 message for updating the location of the subscriber in an HLR. 
However, rather than simply updating the subscriber location in an HLR, the SS7 
message is intercepted, information is extracted from the message, and the information 
is used to update presence information for the target end user in a presence database. 
Claim 5 recites that the presence information includes information usable by a presence 
server for automatically indicating to end users who are subscribed to the target end 
user a presence status for the target end user. Thus, claim 5 recites the concept of 
subscription that is used in the presence protocol and not in mobility management 
protocols. 

Independent claim 22 recites a presence registration and routing node (Figure 3, 
PRR node 300) for updating presence information regarding an end user in a presence 
server database (Figure 8, presence server 410, Figure 9, presence server 426, Figure 
10, presence server 446, or Figure 11, PDM 502). The presence registration and 
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routing node includes a communication module (Figure 3, LIM 320) for receiving an SS7 
message relating to a target end user to which other end users are subscribed in a 
presence database (Figure 8, presence server 410, Figure 9, presence server 426, 
Figure 10, presence server 446, or Figure 11, PDM 502) and for determining whether 
presence registration processing is required for the SS7 message. Two types of SS7 
messages that are described in the specification as being usable for generating 
presence information are ISUP messages and TCAP messages. The receipt of an 
ISUP IAM message by LIM 320 is described on page 19 at lines 17-18 of the present 
specification. The receipt of a TCAP message by LIM 320 is described on page 23, 
lines 13-15 of the present specification. Claim 22 further recites a presence server 
message generator (Figure 3, PRM 340) for, if the communication module (Figure 3, 
LIM 320) determines that presence registration processing is required, receiving a copy 
of the SS7 message and for automatically generating a presence registration message 
including presence information usable by a presence server (Figure 8, presence server 
410, Figure 9, presence server 426, Figure 10, presence server 446, or Figure 11, PDM 
502) for automatically indicating to end users subscribed to the target end user a 
presence status for the target end user and wherein the presence server message 
generator (Figure 3, PRM 340) is adapted to forward the presence registration message 
to the presence database (Figure 8, presence server 410, Figure 9, presence server 
426, Figure 10, presence server 446, or Figure 11, PDM 502). Generation of a 
presence registration message for a received ISUP message is described on page 21, 
line 25 through page 22, line 3 of the present specification. Generation of a presence 
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registration message in response to a received TCAP message is described, for 
example, on page 24, line 24 through page 25, line 2 of the present specification. 

Thus, independent claim 22 recites a system that includes a communication 
module and a presence server message generator that cooperate to generate a 
presence registration message in response to a received SS7 message. Claim 22 also 
indicates that the presence registration message is usable by end users subscribed to a 
target end user a presence status for the target end user. Thus, claim 22 recites the 
subscription concept of the presence protocol. 

Independent claim 29 recites a presence registration and routing node for 
updating presence information regarding an end user in a presence server database 
(Figure 8, presence server 410, Figure 9, presence server 426, Figure 10, presence 
server 446, or Figure 11, PDM 502). The presence registration and routing node 
(Figure 3, PRR node 300) includes a communication module (Figure 3, LIM 320) for 
receiving an SS7 message from an SS7 network. The receipt of an SS7 ISUP message 
by LIM 320 is described on page 19, lines 17-18 of the present specification. The 
receipt of an SS7 TCAP message by LIM 320 is described on page 23, lines 13-15 of 
the present specification. 

Claim 29 further recites a presence server message generator (Figure 3, PRM 
340) for generating, based on the SS7 message, a presence-server-compatible 
message (Figure 8, registration message 416, Figure 9, registration message 434, or 
Figure 10, registration message 450) for updating presence information regarding a 
target end user in a presence server database (Figure 8, presence server 410, Figure 9, 
presence server 426, Figure 10, presence server 446, or Figure 11, PDM 502). The 
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presence information includes a presence status for the target end user. The presence 
server message generator (Figure 3, PRM 340) is adapted to forward the presence- 
server-compatible message (Figure 8, registration message 416, Figure 9, registration 
message 434, or Figure 10, registration message 450) to the presence server database 
(Figure 8, presence server 410, Figure 9, presence server 426, Figure 10, presence 
server 446, or Figure 11, PDM 502). The forwarding of a presence-server-compatible 
message to a presence server database by PRM 320 in response to receiving an ISUP 
message is described on page 22, lines 21-22 of the present specification. The 
forwarding of a presence registration message generated in response to a received 
TCAP message to a presence database is described on page 25, lines 13-15 of the 
present specification. 

Thus, independent claim 29 recites a presence registration and routing node that 
includes a communication module and a presence server message generator. The 
communication module receives SS7 messages. The presence server message 
generator generates a presence registration message in response to the received SS7 
message and forwards the message to a presence server database. 

Independent claim 42 recites a computer program product comprising computer 
executable instructions embodied in a computer readable medium for performing steps. 
The steps include receiving a signaling system 7 (SS7) message (Figure 8, location 
update message 412, Figure 9, ISUP IAM message 428, or Figure 10, TCAP message 
448) in response to a telephony-related action performed by a target end user (Figure 8, 
mobile subscriber 402, Figure 9, wireline subscriber 422, or Figure 10, wireline 
subscriber 442). Page 19, lines 17-19 of the present specification describe receipt of an 
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ISUP 1AM message by presence registration routing node 300. Page 23, lines 13-15 
describe receipt of a TCAP message by presence registration routing node 300. 
Examples of telephony-related actions described in the present specification are 
registration of a wireless customer in a particular cell or service area (see page 26, lines 
7-18 of the present specification), the placement of a wireline telephone call (see page 
27, lines 6-19 of the present specification), or the dialing of a code via a telephone 
keypad (see page 28, lines 3-13 of the present specification). 

Claim 42 further recites, in response to receiving the SS7 message (Figure 8, 
location update message 412, Figure 9, ISUP IAM message 428, or Figure 10, TCAP 
message 448), formulating an Internet protocol message (Figure 8, registration 
message 416, Figure 9, registration message 434, or Figure 10, registration message 
450) for updating presence information regarding the target end user managed by a 
presence server (Figure 8, presence server 410, Figure 9, presence server 426, Figure 
10, presence server 446, or Figure 11, PDM 502) for automatically indicating to end 
users who are subscribed to the target end user in a presence server database (Figure 
8, presence server 410, Figure 9, presence server 426, Figure 10, presence server 446, 
or Figure 11, PDM 502) a presence status for the target end user. Generation of the 
presence registration messages in response to received location update messages is 
described on page 26, lines 7-12 of the present specification. For ISUP IAM messages, 
the generation of IP-based presence registration message is described on page 27, 
lines 1-3 of the present specification. The generation of an IP-based presence 
registration message in response to a TCAP message is described on page 28, lines 9- 
13 of the present specification. 



- 13- 



Serial No.: 09/627,253 

Thus, independent claim 42 recites a computer program product that includes 
computer executable instructions for performing the steps of generating a presence 
registration message in response to a received SS7 message. The presence 
registration message includes information usable by a presence server for automatically 
indicating to other users subscribed to the target end user in a presence server 
database a presence status for the target end user. Thus, independent claim 42 recites 
the concept of a subscription used in the presence protocol. 
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VL Grounds of Rejection to be Reviewed on Appeal 
The grounds for rejection for review are: 

(1) The rejection of claims 1, 4, 6, 10, 22, 23, 28-33, 42, 45-47, 61-65, 69, 71, 
and 75 under 35 U.S.C. § 103(a) as unpatentable over U.S. Patent No. 
6,718,178 to Sladek (hereinafter, ''Sladek") in view of U.S. Patent No. 
6,61 1 ,516 to Pirkola et al . (hereinafter, " Pirkola "); 

(2) The rejection of claims 2, 3, 27, 43, and 44 under 35 U.S.C. § 103(a) as 
unpatentable over Sladek in view of Pirkola and further in view of U.S. 
Patent No. 6,430,176 to Christie, IV (hereinafter, " Christie "); and 

(3) The rejection of claims 7-9, 24, 26, 34, 48-50, 66, 70, 72, and 76 under 35 
U.S.C. § 103(a) as unpatentable over Sladek in view of Pirkola and further 
in view of U.S. Patent No. 6,564,261 to Gudionsson et al . (hereinafter, 
" Gudionsson "). 
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VII . Arguments 

A. Rejection of claims 1, 4, 6. 10. 22-23, 25. 28-33, 42, 45-47, 61-65. 69, 71 and 75 
under 35 U.S.C. § 103(a) as unpatentable over Sladek in view of Pirkola 
i. Argument for independent claim 1 

The rejection of claim 1 as unpatentable over Sladek in view of Pirkola should be 
reversed because neither document teaches or suggests a method for updating 
presence information in a presence database where the method includes receiving an 
SS7 message, determining whether presence processing is required, in response to 
determining that presence registration processing is required, automatically generating 
a presence registration message. Neither Sladek nor Pirkola has anything to do with 
the presence protocol, not to mention generating a presence registration message 
based on a SS7 message that is generated in response to a telephony-related action. 
As will be explained in detail below, both Sladek and Pirkola disclose mobility 
management messages commonly used in wireless telephone networks, and these 
messages are not presence registration messages. Claim 1 also recites that the 
presence registration message includes presence information usable by a presence 
server for automatically indicating to end users who are subscribed to the target end 
user in a presence database a presence status for the target end user. The mobility 
management protocols of Sladek and Pirkola do not include the concept of one user 
subscribing to another user. Rather, the mobility management protocols are used by 
the network to track a mobile subscribers location. 

Rather than teaching a method that relates to relates to generating a presence 
registration message based on receipt of a SS7 message, Sladek relates to a method 
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for automatically delivering short message service (SMS) messages to a calling party 
(See, e.g., column 15, line 14 of Sladek ), a called party (See, e.g., column 15, line 7 of 
Sladek), or a third party (See, e.g., column 8, lines 39-52 of Sladek ), in response to call 
processing event. SMS messages are text messages delivered over the 
telecommunications signaling network. Automatically delivering such messages has 
nothing to do with a presence registration message including presence information 
usable by a presence server for automatically indicating to end users who are 
subscribed to the target end user in the presence database a presence status for the 
target end user. SMS is a text messaging protocol used to communicate information to 
end users. There is no ability in this protocol for subscribers to subscribe to other 
subscribers for receiving updates in presence status information. Rather than teaching 
the updating of presence status information, Sladek merely teaches conventional IS-41 
signaling messages used for delivering SMS messages. For example, Sladek states: 

In particular, CPE maybe programmed to send an IS-41 SMSREQ message to 
the HLR of SME 24 (possibly to one or more HLRs) and to receive a response 
smsreq message from the HLR, providing the sms_address of SME 24 
(assuming that the destination SME is available. The sms_address may 
comprise the SS7 point code of the serving system that serves the SME 24, for 
instance. (See column 12, lines 25-32 of Sladek .) 

The above-quoted passage from Sladek discusses how customer premises equipment 

(CPE) obtains the address of a destination short message entity (SME) from a home 

location register (HLR). The SMS request message is a message used by the CPE to 

obtain the point code (network node address) of the system where the intended short 

message recipient (SME) is currently located. The SMS request message is not a 

presence registration message. Rather, it is a query directed to a HLR. An HLR is not 
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a presence server or a presence database. Rather, it is a node that stores mobile 
subscription information used by the network and does not allow subscribers to 
subscribe to other subscribers. Accordingly, for these reasons, Sladek fails to teach or 
even remotely suggest a method that includes generating a presence registration 
message in response to an SS7 message where the presence registration message 
includes information usable by a presence server for automatically indicating to end 
users who are subscribed to the target end user in a presence database a presence 
status for the target end user. 

Pirkola likewise lacks such teaching or suggestion. Pirkda, like Sladek , has 
nothing to do with generating a presence registration message, not to mention 
generating such a message in response to receiving an SS7 signaling message as 
claimed. In contrast, Pirkola is directed to a system for maintaining updated status and 
location information in a subscriber's home function each time a subscriber changes 
location. In Figure 2 of Pirkola , the home function 266 is a gateway mobile switching 
center (MSC) and the HLR that serve the subscriber. As stated above, a HLR is a 
node that stores mobile subscriber's subscription information and has nothing to do 
with presence information. The messages sent to an HLR include mobility 
management and query messages, none of which are presence registration 
messages. A gateway MSC is an end office switch in a mobile communications 
network, which does not store, generate, or process presence information. The 
function of a gateway MSC is to set up calls to mobile subscribers. Since neither the 
HLR or the gateway MSC that make up the home function of Pirkola store or generate 
presence registration information, the home function of Pirkola does not perform the 
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actions of generating a presence message in response to a SS7 message generated 
in response to a telephony-related action by an end user. 

With regard to subscriber registration, Pirkola indicates that visited function 274 
illustrated in Figure 2 provides the subscriber's current location to the home function 
for the purpose of delivering calls to the subscriber (See column 13, lines 1-21 of 
Pirkola ). Visited function 274 includes the VLR and the MSC currently serving the 
subscriber. The process of delivering the subscriber's current location to the home 
function is a standard mobility management protocol function used in mobile 
communications networks and has nothing to do with generating a presence 
registration message. As recited in claim 1 , a presence registration message includes 
information usable by a presence server for automatically indicating to subscribers who 
are subscribed to a target end user a presence status for the target end user. This 
message is generated in response to an SS7 message. The mobility management 
messages of Pirkola and Sladek are IS-41 messages. Unless a presence server is 
modified to participate in mobility management protocols, the presence server will 
discard such messages. Accordingly, because Pirkola and Sladek fail to teach the 
invention claimed in claim 1, it is respectfully submitted that the rejection of claim as 
unpatentable over Sladek in view of Pirkola should be reversed. 

In paragraph (c) on page 3, the Official Action dated June 2, 2005 misinterprets 
Sladek . For example, paragraph (c) on page 3 of the Official Action states: 

in response to determining that presence registration processing is 
required for the target end user (figure 8, reference 48), automatically 
generating a presence registration message including presence 
information usable by a presence server (figure 8, reference 42) for 
automatically indicating to the end users in a presence database (figure 8, 
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reference 44) a presence status for the target end user (figure 8, reference 
48) (col. 14 line 37 to col. 15 line 7) 

The above-quoted passage indicates that Figure 8, reference numeral 48 of 
Sladek teaches the claim element of "in response to determining that presence 
registration processing is required for the target end user." Figure 8, reference 
numeral 48 of Sladek is the destination short message entity (SME) 48. Sladek 
indicates that SME 48 receives a text message identifying a caller (See column 14, 
lines 60-64 of Sladek ). Presence registration processing with regard to SME 48 is not 
discussed anywhere in Sladek . 

The above-quoted paragraph from the Official Action further indicates that 
Figure 8, reference 42 of Sladek discloses the claim element of "automatically 
generating presence registration message including presence information usable by a 
presence server." Appellants respectfully disagree. Figure 8, reference numeral 42 of 
Sladek is the SMS logic. According to Sladek , the SMS logic determines the address 
of a destination subscriber and sends a text message to the subscriber. As stated 
above, the protocols used to locate the subscriber are standard IS-41 mobility 
management signaling protocols, rather than presence registration messages. Such 
IS-41 messages would be discarded by a presence server, because they are not 
compliant with the presence protocol. 

The above-quoted passage from the Official Action further indicates that Figure 
8, reference 44 of Sladek discloses the claim element of "automatically indicating to 
end users in a presence database." Appellants respectfully disagree. Figure 8, 
reference 44 of Sladek refers to a subscriber profiles database. According to Sladek , 
subscriber profiles define, "for a given subscriber or group of subscribers, what service 
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the subscriber or group subscribes to." (See column 13, lines 35-39 of Sladek.) The 
subscriber profiles of Sladek allow subscribers to subscribe to services, such as 
automatic SMS service. There is absolutely no description of allowing the subscribers 
to subscribe to other subscribers as claimed in claim 1 . 

The above-quoted passage from paragraph (c) of the Official Action further 
indicates that Figure 8, reference 48 and column 14, line 37- column 15, line 7 of 
Sladek disclose the claim element of "a presence status for the target end user." As 
stated above, Figure 8, reference 48 of Sladek is a destination short message entity 
that receives a short message. Neither the short message nor the mobility 
management messaging used to locate SME 48 is a presence registration message 
that updates the presence status of a target end user to which other users are 
subscribed. Column 14, line 37 - column 15, line 7 of Sladek discuss the delivery of a 
short message to SME 48. As stated above, none of this messaging is a presence 
registration message as claimed in claim 1 . Thus, because the Official Action dated 
June 2, 2005 misinterprets Sladek , for this additional reason it is respectfully submitted 
that the rejection of claim 1 as unpatentable over Sladek in view of Pirkola should be 
reversed. 

ii. Argument for dependent claims 4, 6, 1 0, and 64 

The claims 4, 6, 10, and 64 depend from and further limit claim 1. Accordingly, 
the rejection of these claims as unpatentable over Sladek in view of Pirkola should be 
reversed for the same reasons stated above with regard to independent claim 1 . 
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iii. Argument for dependent claim 65 

Claim 65 depends and further limits claim 1. Therefore, for the same reasons 
stated above with regard to the rejection of claim 1, the rejection of claim 65 as 
unpatentable over Sladek in view of Pirkola should be reversed. Moreover, claim 65 
recites that the steps in claim 1 are performed at an SS7 signal transfer point capable of 
transferring SS7 signaling messages between SS7 signaling links. Neither Sladek nor 
Pirkola mentions an SS7 signaling transfer point, not to mention an SS7 signal transfer 
point that generates a presence registration message in response to receipt of an SS7 
message as claimed. Thus, for this additional reason, the rejection of claim 65 as 
unpatentable over Sladek in view of Pirkola should be reversed. 

iy. Argument for independent claim 5 

The rejection of claim 5 should be reversed because Sladek and Pirkola fail to 
teach or suggest a method for updating presence information regarding a target end 
user in a presence database based on information derived from an SS7 message where 
the method includes receiving an SS7 message in response to a telephony-related 
action performed by a target end user, where the telephony-related action is the 
activation or change in location of a mobile telephone handset and the SS7 message is 
a message for updating the status of the target end user in HLR and/or VLR. Sladek 
and Pirkola likewise fail to teach or suggest intercepting the SS7 message, extracting 
information form the SS7 message, and using the information extracted from the SS7 
message to update presence information for the target end user in a presence 
database. The presence information is defined in claim 5 as information usable by a 
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presence server automatically indicating two users who are subscribed to the end target 
user a presence status for the target end user. Thus, claim 5, like claim 1, recites 
updating presence information in response to an SS7 message. Claim 5 further recites 
that the SS7 message is a message for updating the status of a target end user in a 
HLR or VLR. 

As stated above with regard to the rejection of claim 1 , Sladek and Pirkola fail to 
discuss the generation of any presence information usable by subscribers who are 
subscribed to a target end user. Sladek is directed to an automatic SMS messaging 
system where a subscriber can subscribe to a service for receiving text messages, such 
as messages that indicate the identity of a caller. Pirkola is likewise directed to 
delivering text messages to subscribers. Both Sladek and Pirkola discuss the use of 
standard mobility management messages to update information regarding a subscriber 
in a HLR or VLR. However, neither document discloses intercepting such mobility 
management messages and generating or updating presence information based on 
such messages as claimed in claim 5. Accordingly, for these reasons, it is respectfully 
submitted that the rejection of claim 5 as unpatentable over Sladek in view of Pirkola 
should be reversed. 

With regard to claim 5, page 5, second paragraph, of the Official Action dated 
June 2, 2005 states: 

One skilled in the art would have recognized change in location of a 
mobile telephone handset to use the teachings of Pirkola et al. in the 
system of Sladek et al. Therefore, it would have been obvious to a person 
of ordinary skill in the art at the time of the invention, to use the change in 
location of a mobile telephone handset as taught by Pirkola et al. in 
Sladek et al. system with a motivation being to update the subscriber's 
record in the HLR (column 3, lines 4-5). (Emphasis added.) 
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From the above-quoted passage, the Official Action incorrectly equates updating the 
HLR of Pirkola with updating presence information for a subscriber in a presence 
server. As stated above, an HLR is not a presence server because (1 ) it does not allow 
subscribers to subscribe to other subscribers, (2) it uses mobility management protocols 
rather than presence protocols, (3) it does not receive messages including information 
derived from SS7 messages regarding a user's presence status, and (4) it 
communicates with the network rather than with subscribers. Accordingly, for this 
additional reason, it is respectfully submitted that the rejection of claim 5 as 
unpatentable over Sladek in view of Pirkola should be reversed. 

y. Argument for independent claim 22 

The rejection of independent claim 22 as unpatentable over Sladek in view of 
Pirkola should be reversed because Sladek and Pirkola fail to teach or suggest a 
presence registration and routing node that includes a communication module and a 
presence server message generator for receiving an SS7 message, generating a copy 
of the message, and for automatically generating a presence registration message 
including presence information usable by a presence server for automatically indicating 
to end users subscribed to a target end user in a presence server a presence status for 
the target end user, or forwarding such a message to a presence database. As stated 
above with regard to the rejection of claim 1, Sladek and Pirkola are both directed to 
delivering SMS messages to subscribers. Neither mentions generating a presence 
registration message. Both Sladek and Pirkola discuss querying and HLR to determine 
a destination subscriber's current location and delivering SMS messages to that 
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location. The protocol for obtaining a subscriber's location information is standard IS-41 
messaging. There is no mention in either document of generating a presence 
registration message based on mobility management messaging. Moreover, the only 
subscription referred to in these documents is in Sladek where a subscriber can 
subscribe to a service, such as automatic SMS messaging service. There is no mention 
of generating any information usable by subscribers who subscribed to other users as 
claimed in claim 22. 

In addition, claim 22 recites that the presence server message generator 
forwards the presence registration message to a presence database. On page 6, the 
Official Action dated June 2, 2005 indicates that column 14, line 37 to column 15, line 7 
of Sladek disclose forwarding the presence registration message to a presence 
database. Column 14, line 37 through column 15, line 7 of Sladek state as follows: 



Referring now to FIG. 9, at step 52, when CCP 34 receives the 
TCAP message, its core service logic 40 responsively parses the 
message and stores the parameters of the message in memory. At step 
54, core logic 40 then queries subscriber profile database 44 to obtain the 
subscriber profile for MS 46, by reference to its MSID for example. Based 
on this profile, at step 56, core logic 40 calls SMS logic 42. At step 58, 
SMS logic 42 then references the subscriber profile and stored TCAP 
parameters, and SMS logic 42 determines that, since the dialed digits 
represent an 314 code number, CCP 34 should generate the specified 
message to be sent to MS-based SME 48. 

At step 60, SMS logic 42 generates the specified text message. In 
doing so, SMS logic 42 retrieves the partially canned message from Mr. 
Smith's profile and notes that the message is supposed to include the 
name of the called party and the date and time of the call. Given only the 
number of the called party, SMS logic 42 concludes that it must convert 
the dialed digits into the name of the called party. Thus, SMS logic 42 
queries name/number database 50, to identify the subscriber name 
corresponding to the dialed subscriber number, and the database returns 
a string value, "Pete Harrison". In addition, SMS logic 42 identifies the 
current time as 14:34:03 and the current date as Jul. 29, 2004. SMS logic 
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42 then inserts these parameters into the partially defined message and 
establishes a complete informational text message, which reads, "George 
Smith called Pete Harrison at 14:34:03 on Jul. 29, 2004. 

At step 62, SMS logic 42 (or another module of CPE 34) then 
sends an SMD-REQ message to the HLR of MS 48 and obtains in 
response an SMS_Address identifying the point code of the MSC 26 that 
is currently serving MS 48. At step 64, SMS logic 42 then generates an 
SMDPP message carrying the derived informational text message as 
bearer data and sends the message to MSC 26. Finally, at step 66, upon 
receipt of the SMDPP, MSC 26 then delivers the SMS message to MS 48, 
where the text message is displayed for viewing by Pete Harrison. 

The above-quoted passage from Sladek discusses the sending of a TCAP message to 

subscriber profiles database 44, determining the type of SMS message to send to a 

caller based on digits dialed by the caller, and sending the SMS message to the caller. 

The entities involved in this transaction include SMS logic 42, profiles database 44, an 

HLR, and an MSC. None of these entities is a presence server. SMS logic 42 delivers 

SMS messages. Profiles database 44 stores information regarding the type of services 

to which the caller subscribers. The HLR tracks the subscriber's location. The MSC 

delivers the SMS message to the subscriber. None of these entities is a presence 

database that stores presence information and that allows subscribers to subscribe to 

other subscribers. Accordingly, for these reasons, it is respectfully submitted that the 

rejection of independent claim 22 as unpatentable over Sladek in view of Pirkola should 

be reversed. 



yi. Argument for dependent claims 23, 25, 28. 33, and 62 

Claims 23, 25, 28, 33, and 62 depend from and further limit claim 22. 
Accordingly, for the same reasons stated above with regard to independent claim 22, it 
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is respectfully submitted that the rejection of these claims as unpatentable over Sladek 
in view of Pirkola should be reversed. 

vji. Argument for dependent claim 69 

Claim 69 depends from and further limits claim 22. Accordingly, for the same 
reasons stated above with regard to independent claim 22, it is respectfully submitted 
that the rejection of claim 69 as unpatentable over Sladek in view of Pirkola should be 
reversed. Moreover, claim 69 recites that the communication module includes SS7 
signal transfer functionality for transferring SS7 signaling messages between SS7 
signaling links. Neither Pirkola nor Sladek mentions any device that has SS7 signal 
transfer functionality. Both Sladek and Pirkola mention various nodes that originate and 
terminate SS7 signaling messages, but none of the nodes transfer, i.e., route, SS7 
signaling messages between SS7 signaling links as preformed by a signal transfer 
point. Accordingly, for this additional reason, the rejection of claim 69 as unpatentable 
over Sladek in view of Pirkola should be reversed. 

viii . Argument for independent claim 29 

The rejection of independent claim 29 as unpatentable over Sladek in view of 
Pirkola should be reversed because Sladek and Pirkola fail to teach or suggest a 
presence registration and routing node that includes a communication module and a 
presence server message generator that performs the functions recited in independent 
claim 29. For example, according to independent claim 29, the communication module 
receives a SS7 message from a SS7 network. The presence server message 
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generator generates, based on the SS7 message, a presence-server-compatible 
message for updating presence information regarding a target end user in a presence 
server database. Claim 29 further recites that the presence information includes a 
presences status for the target end user in that the presence server message generator 
forwards the presence server compatible message to the presence server database. 

Because claim 29 recites the generation of a presence-server-compatible 
message for updating presence information regarding a target end user in a presence 
server database based on a SS7 message, the reasoning stated above with regard to 
the rejection of claim 1 as unpatentable over Sladek in view of Pirkola applies equally to 
claim 29. That is, neither Sladek nor Pirkola teaches or suggests generating a 
presence-server-compatible message. Both documents relate to generating SMS 
messages and obtaining subscriber location information for delivering the SMS 
messages to a subscriber. None of the mobility management messages discussed in 
either document are presence-server-compatible messages. Rather, such messages 
are IS-41 mobility management messages exchanged between HLRs and VLRs. In 
addition, the Official Action dated June 2, 2005, incorrectly indicates that the actions 
performed by SMS logic 32 and subscriber profiles database 44 of Sladek include 
delivering a presence-server-compatible message to a presence server database. SMS 
logic 42 of Sladek delivers SMS messages to end users. Subscriber profiles database 
44 in Sladek stores services to which a subscriber can subscribe and is not a presence 
server database. Nowhere does Sladek indicate that subscriber profiles database 44 
allows a subscriber to subscribe to other subscribers for receiving presence information 
for the other subscribers. Accordingly, for these reasons, it is respectfully submitted 



-28- 



Serial No.: 09/627,253 

that the rejection of independent claim 29 as unpatentable over Sladek in view of 
Pirkola should be reversed. 

ix. Argument for dependent claims 30-32 

Claims 30-32 depend from and further limit claim 29. Therefore, for the same 
reasons stated above with regard to the rejection of independent claim 29 it is 
respectfully submitted that the rejection of these claims as unpatentable over Sladek in 
view of Pirkola should be reversed. 

x. Argument for dependent claim 71 

Claim 71 depends from and further limits claim 29. Therefore, for the same 
reasons stated above with regard to independent claim 29, the rejection of claim 71 as 
unpatentable over Sladek in view of Pirkola should be reversed. Moreover, claim 71 
recites that the steps recited in claim 29 are performed at an SS7 signal transfer point 
capable of transferring SS7 signaling messages between SS7 signaling links. Neither 
Sladek nor Pirkola mentions a SS7 signal transfer point. Both documents discuss 
nodes that originate and terminate SS7 messages. However, neither mentions a signal 
transfer point that routes or transfers SS7 signaling messages between SS7 signaling 
links, not to mention a signal transfer point that generates a presence registration 
message based on a received SS7 signaling message as claimed in claim 71. 
Accordingly, for this additional reason, the rejection of claim 71 as unpatentable over 
Sladek in view of Pirkola should be reversed. 
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xi. Argument for independent claim 42 

The rejection of independent claim 42 as unpatentable over Sladek in view of 
Pirkola should be reversed because Sladek and Pirkola fail to teach a computer 
program product comprising computer executable instructions embodied in the 
computer readable media for performing the steps recited in claim 42 of receiving a SS7 
message and generating an IP message for updating presence information regarding 
the target end user managed by a presence server, where the presence information 
includes information usable by a presence server for automatically indicating to end 
users who are subscribed to the target end user in a presence database a presence 
status for the target end user. Claim 42 further recites transmitting the IP message to a 
presence server over an IP network. As stated above with regard to the rejection of 
independent claim 1 , neither Sladek nor Pirkola disclose generating a message for 
updating presence information regarding a target end user or forwarding such a 
message to a presence database. Both documents are directed to delivering SMS 
messages to subscribers and tracking the location of the subscribers using standard 
mobility management protocols. Accordingly, for this reason alone, the rejection of 
claim 42 as unpatentable over Sladek in view of Pirkola should be withdrawn. 

Moreover, on page 8 of the Official Action dated June 2, 2005, the Examiner 
indicates that column 7, lines 10-12 of Sladek disclose the claim element of, 
"transmitting the IP message to a presence server over an IP network." This is simply 
incorrect. Column 7, lines 10-12 of Sladek state as follows: 

(Alternatively, as another example, if the transport network is IP (internet 
protocol )-based, the SMS_Address parameter may contain an IP 
address.) 
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The above-quoted passage from Sladek indicates that the SMS__address parameter 
may include an IP address. According to Sladek , the SMS_address parameter is used 
to route short messages to the serving system for delivery to a destination. The 
SMS_address parameter is communicated to a mobile station's HLR in a registration 
notification (REGNOT) message. As stated above, an HLR is not a presence server 
because it does not allow subscribers to subscribe to other subscribers, it does not use 
the presence protocol, it communicates with the network rather than with subscribers 
and it does not receive messages that include presence information derived from SS7 
messages. Accordingly, because the Official Action misinterprets Sladek , for this 
additional reason, it is respectfully submitted that the rejection of claim 42 as 
unpatentable over Sladek in view of Pirkola should be reversed. 

Yet another reason that the rejection of claim 42 should be reversed is that the 
Official Action dated June 2, 2005 incorrectly indicates that column 2, lines 62-65 of 
Pirkola disclose updating presence information regarding the target end user managed 
by a presence server. This is incorrect. Column 2, lines 62-65 of Pirkola state as 
follows: 

When a visiting (or roaming) cellular subscriber is detected in a serving 
system, the location update processes notify the subscriber's HLR of the 
subscriber's presence in the serving system. 

The above-quoted passage from Pirkola discusses informing the subscriber's HLR of 

the subscriber's new location in a serving system. For the reasons stated above, it is 

respectfully submitted that an HLR is not a presence server. Accordingly, for this 
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additional reason, it is respectfully submitted that the rejection of claim 42 as 
unpatentable over Sladek in view of Pirkola should be reversed. 

xii. Argument for dependent claims 45-47 

Claims 45-47 depend from and further limit claim 42. Accordingly, for the same 
reasons stated above with regard to claim 42, the rejection of these claims as 
unpatentable over Sladek in view of Pirkola should be reversed. 

xiii . Argument for dependent claim 75 

Claim 75 depends from and further limits claim 42. Therefore, for the same 
reasons stated above with regard to claim 42, the rejection of claim 75 as unpatentable 
over Sladek in view of Pirkola should be reversed. Moreover, claim 75 recites that the 
steps of claim 42 are performed on a SS7 signal transfer point capable of transferring 
SS7 signaling message between SS7 signaling links. As stated above, neither Sladek 
nor Pirkola mentions an SS7 signal transfer point. Both Sladek and Pirkola discuss 
nodes that originate and terminate SS7 messages. However, neither document 
discloses a SS7 signal transfer point that transfers SS7 signaling messages between 
SS7 signaling links and that formulates an IP message containing presence information 
as claimed in claim 75. Accordingly, for this additional reason, the rejection of claim 75 
as unpatentable over Sladek in view of Pirkola should be reversed. 
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B. Rejection of claims 2, 3. 27, 43, and 44 under 35 U.S.C. § 103(a) as 
unpatentable over Sladek in view of Pirkola and further in view of Christie 

i. Argument for dependent claims 2 and 3 

Claims 2 and 3 depend from and further limit claim 1. As stated above with 
regard to the rejection of independent claim 1, claim 1 fails to teach or suggest a 
method where a presence registration message is automatically generated in response 
to receipt of an SS7 message. Christie likewise lacks such teaching or suggestion. 
Christie is directed to setting up an integrated voice and data session in response to a 
single telephone call. (See Abstract of Christie .) There is no mention of generating a 
presence registration message. The only messages discussed in Christie are the 
messages used to set up the multimedia session. 

Moreover, dependent claims 2 and 3 respectfully recite the telephony-related 
action from which the presence registration message is triggered is the initiation of a 
telephone call and the dialing of predetermined DTMF digits. Although Christie 
mentions initiating calls and dialing digits, Christie fails to even remotely suggest 
generating a presence registration message in response to either of these actions. 
Accordingly, for this additional reason, the rejection of claims 2 and 3 as unpatentable 
over Sladek in view of Pirkola and further in view of Christie should be reversed. 

ii. Argument for dependent claim 27 

Claim 27 depends from and further limits claim 22. As stated above with regard 
to the rejection of claim 22 as unpatentable over Sladek and Pirkola , Sladek and Pirkola 
fail to teach or suggest a presence registration and routing node with a communication 
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module and a presence server message generator that generate a presence 
registration message in response to receipt of an SS7 message. Christie likewise lacks 
such teaching or suggestion. Christie is directed to setting up integrated voice and data 
sessions between end users and fails to mention the generation of any presence 
registration messages. Accordingly, for this reason alone, the rejection of claim 27 as 
unpatentable over Sladek in view of Pirkola and further in view of Christie should be 
reversed. 

Moreover, claim 27 recites that the SS7 message upon which the presence 
message is based is an ISDN user part (ISUP) message. While Christie mentions 
various ISUP messages, the purpose of these messages is to set up and tear down 
media communications between end users. In contrast, claim 27 recites the ISUP 
message as a trigger for a presence registration message. Since Christie fails to teach 
or even remotely suggest the use of an ISUP message as a trigger for a presence 
registration message, it is respectfully submitted that the rejection of claim 27 should be 
reversed for this additional reason. 

iii. Argument for dependent claims 43 and 44 

Claims 43 and 44 depend from and further limit claim 42. As stated above with 
regard to the rejection of claim 42, Sladek and Pirkola fail to teach or suggest a 
computer program product that performs the steps of generating an IP message for 
updating presence information regarding a target end user in response to receiving an 
SS7 message in response to a telephony-related action by the target end user. Christie 
likewise lacks such teaching or suggestion. Christie is directed to setting up multimedia 
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communications between users. There is no mention of generating any presence 
registration messages. Accordingly, for this reason alone, the rejection of claims 43 and 
44 as unpatentable over Sladek in view of Pirkola and further in view of Christie should 
be reversed. 

Moreover, claims 43 and 44 respectively recite that the trigger used to generate 
the presence registration message is dialing of a number and generation of an 1AM 
message (claim 43) and the dialing of predetermined DTMF digits to instruct an end 
office to generate an SS7 message (claim 44). While Christie discloses various SS7 
messaging and dialing of digits, the purpose of the messaging and the dialing digits is to 
establish the media communications session. There is absolutely no teaching or 
suggestion in Christie of using an 1AM message or dialed digits to generate a presence 
registration message. Thus, for this additional reason, it is respectfully submitted that 
the rejection of claims 43 and 44 as unpatentable over Sladek in view of Pirkola and 
further in view of Christie should be reversed. 

C. Rejection of claims 7-9, 24, 26, 34, 48-50, 66, 70, 72, and 76 under 35 U.S.C. § 
103(a) as unpatentable over Sladek in view of Pirkola and further in view of 
Gudjonsson 
i. Argument for dependent claim 7 

Claims 7 depends from and further limits claim 1 . As stated above with regard to 
the rejection of independent claim 1, Sladek and Pirkola fail to teach or suggest 
automatically generating a presence registration message including presence 
information in response to receipt of an SS7 message as claimed in claim 1. 
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Gudionsson likewise lacks such teaching or suggestion. Gudionsson , like Sladek and 
Pirkola , has nothing to do with deriving or updating presence information stored by a 
presence server. Rather, Gudionsson is directed to a communications network where a 
cluster of servers 1 allows users to set up multimedia communications with other users. 
There is no mention of generating a presence registration message in response to an 
SS7 message. Accordingly, for this reason alone, the rejection of claim 7 as 
unpatentable over Sladek in view of Pirkola and further in view of Gudionsson should be 
reversed. 

Moreover, claim 7 recites that the presence registration message comprises a 
SIP message. The Official Action correctly notes that Gudionsson mentions the SIP 
protocol. However, Gudionsson fails to teach or suggest using the SIP protocol for a 
presence registration message. For example, with regard to the SIP protocol, 
Gudionsson states: 

When a user 7 wishes to establish a communication with another user, 
he/she will invoke some function within his/her client 11, requesting the 
client to send an invitation of a given type to some selected user. The 
user client will then form the correct SIP message and send it to the 
special service within the cluster, called the routing service. (See column 
9, lines 13-19 of Gudionsson .) 

From this passage, Gudionsson indicates that SIP is used to send an invitation for 

setting up a session to an end user. This is conventional use of the SIP protocol and 

has nothing to do with presence registration. Accordingly, for this additional reason, the 

rejection of claim 7 as unpatentable over Sladek in view of Pirkola and further in view of 

Gudionsson should be reversed. 
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ii. Argument for dependent claim 8 

Claim 8 depends from and further limits claim 1. As stated above with regard to 
the rejection of independent claim 1, Sladek and Pirkola fail to teach or suggest 
automatically generating a presence registration message including presence 
information in response to receipt of an SS7 message as claimed in claim 1. 
Gudjonsson likewise lacks such teaching or suggestion. Gudionsson , like Sladek and 
Pirkola , has nothing to do with deriving or updating presence information stored by a 
presence server. Rather, Gudionsson is directed to a communications network where a 
cluster of servers 1 allows users to set up multimedia communications with other users. 
There is no mention of generating a presence registration message in response to an 
SS7 message. Accordingly, for this reason alone, the rejection of claim 8 as 
unpatentable over Sladek in view of Pirkola and further in view of Gudionsson should be 
reversed. 

Moreover, claim 8 recites that the presence registration message comprises an 
IMPP message. The Official Action correctly notes that Gudjonsson mentions the IMPP 
protocol. However, Gudionsson fails to teach or suggest using the IMPP protocol for a 
presence registration message. With regard to the IMPP protocol, Gudionsson states: 

Various companies have created networks running on top of the Internet 
that allow users to send each other short text messages and monitor the 
status of other users, where the status is usually defined as whether a 
user is currently connected to a network or not. This kind of functionality 
is current being considered as the IETF standard called IMPP (instant 
messaging and presence protocol). (See column 2, lines 16-22 of 
Gudionsson .) 
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The above quoted passage from Gudionsson merely states that the IMPP protocol is 
used to communicate status information regarding whether or not users are connected 
to a network. This is the normal use of the IMPP protocol. There is absolutely no 
teaching or suggestion of generating a presence registration message which is an IMPP 
message as claimed in claim 8. Accordingly, for this additional reason, it is respectfully 
submitted that the rejection of claim 8 as unpatentable over Sladek in view of Pirkola 
and further in view of Gudionsson should be reversed. 

iii. Argument for dependent claims 9 and 66 

Claims 9 and 66 depend from and further limit claim 1. As stated above with 
regard to the rejection of claim 1 , Pirkola and Sladek fail to teach or even remotely 
suggest generating a presence registration message in response to an SS7 message 
as claimed in claim 1. Gudionsson likewise lacks such teach or suggestion. As stated 
above, Gudionsson mentions using both SIP and IMPP protocols. However, the SIP 
protocol is disclosed as being used to set up multimedia sessions. The IMPP protocol 
is disclosed as being used to distribute text messages between users. There is no 
description of generating the presence registration message in response to an SS7 
message as claimed in independent claim 1. Thus, for these reasons, the rejection of 
claims 9 and 66 as unpatentable over Sladek in view of Pirkola and further in view of 
Gudionsson should be reversed. 
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iv. Argument for dependent claim 24 

Claim 24 depends from and further limits claim 22. As stated above with regard 
to the rejection of claim 22, Sladek and Pirkola fail to teach or suggest the presence 
registration and routing node that includes a communication module and a presence 
server message generator for generating a presence registration message in response 
to receipt of an SS7 message. Gudionsson likewise lacks such teaching or 
suggestion. Gudionsson is directed to setting up multi-media sessions and does not 
discuss presence registration. Accordingly, for this reason alone, the rejection of claim 
24 as unpatentable over Sladek in view of Pirkola and further in view of Gudionsson 
should be reversed. 

Moreover, claim 24 recites that the presence registration message is a SIP 
message. As stated above, Gudionsson mentions only the conventional use of SIP 
messages to establish sessions. There is no disclosure of using a SIP message to 
perform presence registration as claimed in claim 24. Accordingly, for this additional 
reason, the rejection of claim 24 as unpatentable over Sladek in view of Pirkola and 
further in view of Gudionsson should be reversed. 

y. Argument for dependent claims 26, 34, and 70 

Claims 26, 34, and 70 depend from and further limit claim 22. As stated above 
with regard to the rejection of claim 22, Sladek and Pirkola fail to teach or suggest a 
presence registration and routing node that includes a communication module and a 
presence server message generator for generating the presence registration message 
in response to receipt of an SS7 message. Gudionsson likewise lacks such teaching or 
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suggestion. Gudionsson mentions the IMPP protocol. However, Gudionsson fails to 
even remotely suggest generating an IMPP presence registration message in response 
a SS7 message as claimed. Accordingly, it is respectfully submitted that the rejection of 
claims 26, 34, and 70 as unpatentable over Gudionsson in view of Sladek and further in 
view of Pirkola should be reversed. 

yi. Argument for dependent claim 48 

Claim 48 depends from claim 42. As stated above with regard to the rejection of 
claim 42, Sladek and Pirkola fail to teach or suggest a computer program product 
having computer executable instructions that perform the steps of generating and 
transmitting an IP message for updating presence information regarding the target end 
user in response to receipt of an SS7 message for a telephony-related action performed 
by the target end user. Gudionsson likewise lacks such teaching or suggestion. As 
stated above, Gudionsson is directed to setting up multimedia sessions between end 
users. Presence registration is not mentioned. Accordingly, for this reason alone, the 
rejection of claim 48 as unpatentable over Sladek in view of Pirkola and further in view 
of Gudionsson should be reversed. 

Moreover, claim 48 recites that presence registration message is a SIP message. 
Gudionsson only discloses the use of SIP messages to set up multimedia 
communication sessions. There is no mention in Gudionsson of using a SIP message 
to perform a presence registration as claimed in claim 48. Accordingly, for this 
additional reason, the rejection of claim 48 as unpatentable over Sladek in view of 
Pirkola and further in view of Gudionsson should be reversed. 



-40- 



Serial No.: 09/627,253 

vii. Argument for dependent claims 49, 50, and 76 

Claims 49, 50, and 76 depend from and further limit 42. As stated above with 
regard to the rejection of claim 42, Sladek and Pirkola fail to teach or suggest a 
computer program product having computer executable instructions that perform the 
steps of generating an IP message for updating presence information regarding a target 
end user in response to an SS7 signaling message generated for a telephony-related 
action performed by the target end user. Gudionsson likewise lacks such teaching or 
suggestion. Gudionsson is directed to setting up multimedia sessions between end 
users and fails to mention presence registration, not to mention presence registration in 
response to an SS7 message. Accordingly, it is respectfully submitted that the rejection 
of claims 49, 50, and 76 as unpatentable over Sladek in view of Pirkola and further in 
view of Gudionsson should be reversed. 

viii . Argument for dependent claim 72 

Claim 72 depends from and further limits claim 29. As stated above regard to the 
rejection of claim 29, Sladek and Pirkola fail to teach or suggest a presence registration 
and routing node including a communication module and a presence server message 
generator that generate a presence-server-compatible message in response to receipt 
of an SS7 message. Gudionsson likewise lacks such teaching or suggestion. 
Gudionsson is directed to setting up multimedia communication sessions between end 
users and does not mention presence registration. Gudionsson mentions the IMPP 
protocol, but fails to describe how registration is performed for that protocol. 
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Accordingly, it is respectfully submitted that the rejection of claim 72 as unpatentable 
over Sladek in view of Pirkola and further in view of Gudionsson should be reversed. 

For the foregoing reasons, it is respectfully submitted that the Examiner's 
rejections of claims 1-10, 22-34, 42-50, 61-66, 69-72, 75 and 76 should be reversed. 



Respectfully submitted, 



JENKINS, WILSON, TAYLOR & HUNT, P.A. 



Date: June 2. 2006 
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Registration No. 41,085 
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VIII . Claims Appendix 

1. A method for updating presence information regarding a target end user in a 
presence database based on information derived from a telephony-related 
action, the method comprising: 

(a) receiving a signaling system seven (SS7) message in response to a 
telephony-related action performed by a target end user to which other 
end users are subscribed in a presence database; 

(b) determining, based on the SS7 message, whether presence registration 
processing is required for the target end user; 

(c) in response to determining that presence registration processing is 
required for the target end user, automatically generating a presence 
registration message including presence information usable by a presence 
server for automatically indicating to the end users who are subscribed to 
the target end user in a presence database a presence status for the 
target end user; and 

(d) transmitting the presence registration message to the presence server 
over an IP network. 

2. The method of claim 1 wherein the telephony-related action includes dialing a 
called party telephone number utilizing a PSTN telephone to initiate a call from 
the target end user to the called party telephone number and the signaling 
system seven message is an IAM message. 

3. The method of claim 1 wherein the telephony-related action includes entering 
DTMF digits using a PSTN telephone handset after a call has been established, 
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the DTMF digits forming a code for instructing an end office to formulate the SS7 
message. 

The method of claim 3 wherein the SS7 message is a transaction capabilities 
application part (TCAP) message containing presence information for the target 
end user. 

A method for updating presence information regarding a target end user in a 
presence database based on information derived from a signaling message 
relating to a telephony-related action performed by the target end user, the 
method comprising: 

(a) receiving a signaling system 7 (SS7) message in response to a telephony- 
related action performed by a target end user, wherein the telephony- 
related action is the activation or change in location of a mobile telephone 
handset and the SS7 message is a message for updating the status of the 
target end user in at least one of a home location register (HLR) and a 
visitor location register (VLR); and 

(b) intercepting the SS7 message, extracting information from the SS7 
message, and using the information extracted from the SS7 message to 
update presence information for the target end user in a presence 
database, the presence information including information usable by a 
presence server for automatically indicating to end users who are 
subscribed to the target end user a presence status for the target end 
user. 
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6. The method of claim 1 wherein automatically generating a presence registration 
message includes automatically generating a presence protocol message. 

7. The method of claim 1 wherein automatically generating a presence registration 
message includes automatically generating a session initiation protocol (SIP) 
message. 

8. The method of claim 1 wherein automatically generating a presence registration 
message includes automatically generating an instant messaging and presence 
protocol (IMPP) message. 

9. The method of claim 1 comprising, in response to receiving the SS7 message, 
sending a second message to an accounting and billing system. 

10. The method of claim 9 wherein the second message is a copy of the SS7 
message. 

11. A method for processing a query to a presence server database, the method 
comprising: 

(a) receiving, at presence registration and routing node, an IP message for 
determining presence information for a first end user to which other end 
users are subscribed in a presence database, the presence information 
being usable by a presence server for automatically indicating to the end 
users subscribed to the first end user a communication medium for 
contacting the first end user using a text messaging protocol and the fact 
that the first end user is currently available to receive text messaging 
protocol messages via the communications medium; 
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(b) formulating a query to a presence database for obtaining the presence 
information; 

(c) obtaining the presence information from the presence database; and 

(d) forwarding the presence information to a second end user, wherein the 
second end user uses the presence information to determine the 
appropriate communication medium for contacting the first end user using 
the text messaging protocol and the availability of the first end user to 
receive text messaging protocol communications via the communications 
medium. 

12. The method of claim 11 wherein receiving an IP message includes receiving a 
presence protocol message. 

13. The method of claim 12 wherein receiving a presence protocol message includes 
receiving a fetch message requesting presence information regarding the entity. 

14. The method of claim 1 1 wherein forwarding the presence information to a second 
end user includes forwarding a presence protocol message to the second end 
user. 

15. The method of claim 14 wherein forwarding a presence protocol message 
includes forwarding a notify message to the second end user. 

16. The method of claim 11 wherein receiving an IP message includes receiving a 
session initiation protocol (SIP) message. 

17. The method of claim 11 wherein receiving an IP message includes receiving an 
instant messaging and presence protocol (IMPP) message. 
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18. The method of claim 11 wherein obtaining the presence information from the 
presence database includes obtaining the presence information from a presence 
database located internal to the presence registration and routing node. 

19. The method of claim 11 wherein obtaining the presence information from the 
presence database includes obtaining the presence information from a presence 
database located external to the presence registration and routing node. 

20. The method of claim 11 comprising, in response to receiving the IP message, 
sending a second message to an accounting and billing system. 

21. The method of claim 20 wherein the second message is a copy of the IP 
message. 

22. A presence registration and routing node for updating presence information 
regarding an end user in a presence server database, the presence registration 
and routing node comprising: 

(a) a communication module for receiving an SS7 message relating to a 
target end user to which other end users are subscribed in a presence 
database and for determining whether presence registration processing is 
required for the SS7 message; and 

(b) a presence server message generator for, if the communication module 
determines that presence registration processing is required, for receiving 
a copy of the SS7 message and for automatically generating a presence 
registration message including presence information usable by a presence 
server for automatically indicating to the end users subscribed to the 
target end user a presence status for the target end user, wherein the 
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presence server message generator is adapted to forward the presence 
registration message to the presence database. 

23. The presence registration and routing node of claim 22 comprising an advanced 
database communication module for encapsulating the presence registration 
message in an IP packet and transmitting the IP packet to a presence server 
over an IP network. 

24. The presence registration and routing node of claim 22 wherein the presence 
registration message is a session initiation protocol (SIP) message. 

25. The presence registration and routing node of claim 22 wherein the presence 
registration message is a presence protocol message. 

26. The presence registration and routing node of claim 22 wherein the presence 
registration message is an instant messaging and presence protocol (IMPP) 
message. 

27. The presence registration and routing node of claim 22 wherein the SS7 
message is an ISDN user part (ISUP) message. 

28. The presence registration and routing node of claim 22 wherein the SS7 
message is a transaction capabilities application part (TCAP) message. 

29. A presence registration and routing node for updating presence information 
regarding an end user in a presence server database, the presence registration 
and routing node comprising: 

(a) a communication module for receiving an SS7 message from an SS7 
network; and 
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(b) a presence server message generator for generating, based on the SS7 
message, a presence-server-compatible message for updating presence 
information regarding a target end user in a presence server database, the 
presence information including a presence status for the target end user, 
wherein the presence server message generator is adapted to forward the 
presence-server-compatible message to the presence server database. 

30. The presence registration and routing node of claim 22 comprising a presence 
server database operatively associated with the presence server message 
generator for receiving the presence-server-compatible message and for 
updating the presence information in response to the presence-server- 
compatible message. 

31. The presence registration and routing node of claim 30 wherein the presence 
server database is located internal to the presence registration and routing node. 

32. The presence registration and routing node of claim 30 wherein the presence 
server database is located external to the presence registration and routing node. 

33. The presence registration and routing node of claim 22 wherein the presence 
server message generator is adapted to receive presence queries, forward the 
presence queries to a presence server database, and receive responses from 
the presence server database. 

34. The presence registration and routing node of claim 22 comprising: 

(a) means for generating an accounting message based on at least one of the 
SS7 message received by the communication module and the presence- 
server-compatible message; and 
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(b) an accounting and billing system for storing accounting information based 
on the accounting message. 
35. A presence registration and routing node for providing presence information 
regarding an entity, the presence registration and routing node comprising: 

(a) an advanced database communications module for receiving an IP- 
encapsulated presence-server-compatible message for determining 
presence information for a first end user, the presence information 
indicating a communication medium for contacting the first end user using 
a text messaging protocol and the fact that the first end user is currently 
available to receive text messaging protocol messages via the 
communications medium; and 

(b) a presence server message processor operably associated with the 
advanced database communications module for forwarding the presence- 
server-compatible message to a presence server for determining the 
presence information, wherein the presence server stores the presence 
information for the first end user, and subscription information indicating a 
second end user subscribed to automatically receive presence information 
regarding the first end user and sends a response to the presence-server- 
compatible message to the second end user, thereby informing the 
second end user of the appropriate communications medium for 
contacting the first end user using text messaging protocol 
communications and whether the first end user is currently available to 
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receive text messaging protocol messages via the communications 
medium. 

36. The presence registration and routing node of claim 35 wherein the presence 
server message processor is adapted to receive the presence information from 
the presence server and forward the presence information to the advanced 
database communications module. 

37. The presence registration and routing node of claim 36 wherein the advanced 
database communications module is adapted to forward the presence 
information to an endpoint over an IP network. 

38. The presence registration and routing node of claim 35 comprising a presence 
server operatively associated with the presence server message processor for 
providing the presence information to the presence server message processor. 

39. The presence registration and routing node of claim 38 wherein the presence 
server is located internal to the presence registration and routing node. 

40. The presence registration and routing node of claim 38 wherein the presence 
server is located external to the presence registration and routing node. 

41 . The presence registration and routing node of claim 35 comprising: 

(a) means for generating an accounting message based on the presence- 
server-compatible message; and 

(b) an accounting and billing system for storing accounting information based 
on the accounting message. 

42. A computer program product comprising computer-executable instructions 
embodied in a computer-readable medium for performing steps comprising: 
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(a) receiving a signaling system seven (SS7) message in response to a 
telephony-related action performed by a target end user; 

(b) in response to receiving the SS7 message, formulating an internet 
protocol (IP) message for updating presence information regarding the 
target end user managed by a presence server, the presence information 
including information usable by the presence server for automatically 
indicating to end users subscribed to the target end user in a presence 
server database a presence status for the target end user; and 

(c) transmitting the IP message to the presence server over an IP network. 

43. The computer program product of claim 42 wherein the telephony-related action 
includes dialing a called party telephone number utilizing a PSTN telephone to 
initiate a call from the target end user to the called party telephone number and 
the signaling system seven message is an 1AM message. 

44. The computer program product of claim 42 wherein the telephony-related action 
includes entering DTMF digits using a PSTN telephone handset after a call has 
been established, the DTMF digits forming a code for instructing an end office to 
formulate the SS7 message. 

45. The computer program product of claim 42 wherein the SS7 message is a 
transaction capabilities application part (TCAP) message containing presence 
information for the target end user. 

46. The computer program product of claim 42 wherein the telephony-related action 
is the activation of a mobile telephone handset and the SS7 message is a 
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message for updating the status of the target end user in at least one of a home 
location register (HLR) and a visitor location register (VLR). 

47. The computer program product of claim 42 wherein formulating an IP message 
includes formulating a presence protocol message. 

48. The computer program product of claim 42 wherein formulating an IP message 
includes formulating a session initiation protocol (SIP) message. 

49. The computer program product of claim 42 wherein formulating an IP message 
includes formulating an instant messaging and presence protocol (IMPP) 
message. 

50. The computer program product of claim 42 comprising generating an accounting 
message in response to at least one of the SS7 message and the IP message 
and forwarding the accounting message to an accounting and billing subsystem. 

51. A computer program product comprising computer executable instructions 
embodied in a computer-readable medium for performing steps comprising: 

(a) receiving, at a presence registration and routing node, an IP message for 
determining presence information for a target entity, the presence 
information including information for contacting the target entity via a text 
messaging protocol; 

(b) formulating a query to a presence database for obtaining the presence 
information; 

(c) obtaining the presence information from the presence database based on 
the query; and 
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(d) forwarding the presence information to an end user subscribed to the 
target entity in the presence database. 

52. The computer program product of claim 51 wherein receiving an IP message 
includes receiving a presence protocol message. 

53. The computer program product of claim 52 wherein receiving a presence 
protocol message includes receiving a fetch message requesting presence 
information regarding the target entity. 

54. The computer program product of claim 51 wherein forwarding the presence 
information to an end user includes forwarding a presence protocol message to 
the end user. 

55. The computer program product of claim 54 wherein forwarding a presence 
protocol message includes forwarding a notify message to the end user. 

56. The computer program product of claim 51 wherein receiving an IP message 
includes receiving a session initiation protocol (SIP) message. 

57. The computer program product of claim 51 wherein receiving an IP message 
includes receiving an instant messaging and presence protocol (IMPP) message. 

58. The computer program product of claim 51 wherein obtaining the presence 
information from the presence database includes obtaining the presence 
information from a presence database located internal to the presence 
registration and routing node. 

59. The computer program product of claim 51 wherein obtaining the presence 
information from the presence database includes obtaining the presence 
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information from a presence database located external to the presence 
registration and routing node. 

60. The computer program product of claim 51 comprising generating an accounting 
message in response to at least one of the IP message and the query and 
forwarding the accounting message to an accounting and billing subsystem. 

61. The method of claim 1 comprising routing the SS7 message to its intended 
destination. 

62. The presence registration and routing node of claim 22 wherein the 
communication module is adapted to route the SS7 message to its intended 
destination. 

63. The method of claim 1 wherein the telephony related action comprises activation 
of the end user's mobile telephone and wherein the presence information 
indicates that the target end user is currently reachable to receive messaging 
protocol communications via the target end user's mobile telephone. 

64. The method of claim 1 wherein the telephony related action comprises entering a 
predetermined code via the target end user's wireline telephone and wherein the 
presence information indicates that the target end user is currently reachable via 
the end user's wireline telephone. 

65. The method of claim 1 wherein steps (a)-(e) are performed at an SS7 signal 
transfer point capable of transferring SS7 signaling messages between SS7 
signaling links. 
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66. The method of claim 1 wherein the presence information includes information 
usable by the users subscribed to the target end user for contacting the target 
end user via an instant messaging protocol. 

67. The method of claim 1 1 wherein steps (a)-(d) are performed at an SS7 signal 
transfer point capable of transferring SS7 signaling messages between SS7 
signaling links. 

68. The method of claim 11 wherein the text messaging protocol comprises an 
instant message protocol. 

69. The presence registration and routing node of claim 22 wherein the 
communication module includes SS7 signal transfer functionality for transferring 
SS7 signaling messages between SS7 signaling links. 

70. The presence registration and routing node of claim 22 wherein the messaging 
protocol comprises an instant message protocol. 

71. The method of claim 29 wherein steps (a)-(d) are performed at an SS7 signal 
transfer point capable of transferring SS7 signaling messages between SS7 
signaling links. 

72. The presence registration and routing node of claim 29 wherein the presence 
information includes information usable by the users subscribed to the target end 
user for contacting the target end user via an instant message protocol. 

73. The presence registration and routing node of claim 35 wherein the advanced 
database communications module is adapted to transfer IP-encapsulated SS7 
signaling messages between IP signaling links. 
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74. The presence registration and routing node of claim 35 wherein the text 
messaging protocol comprises presence information includes information usable 
by the users subscribed to the target end user for contacting the target end user 
via an instant message messaging protocol. 

75. The computer program product of claim 42 wherein steps (a)-(c) are performed 
on an SS7 signal transfer point capable of transferring SS7 messages between 
SS7 signaling links. 

76. The computer program products of claim 42 wherein the text messaging protocol 
comprises presence information includes information usable by the users 
subscribed to the target end user for contacting the target end user via an instant 
messaging protocol. 

77. The computer program product of claim 51 wherein steps (a)-(c) are performed 
on an SS7 signal transfer point capable of transferring SS7 messages between 
SS7 signaling links. 

78. The computer program products of claim 51 wherein the text messaging protocol 
comprises an instant messaging protocol. 
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IX. Evidence Appendix 
None 
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